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DESCRIPTION 

SUPPORTING CALIBRATION AND DIAGNOSTICS IN AN OPEN 
ARCHITECTURE TEST SYSTEM 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application claims the benefit of application no. 60/573,577, "Software 
Development in an Open Architecture Test System," filed by Advantest Corporation on May 
22, 2004, which is incorporated, herein in its entirety by reference. 

FIELD OF THE INVENTION 
[0002] The present invention relates to the field of automated test equipment (ATE). In 
particular, the present invention relates to a method and system for supporting calibration 
and/or diagnostics in an open architecture test system. 

BACKGROUND OF THE INVENTION 
[0003] The increasing complexity of System-on-a-Chip (SOC) devices and the 
simultaneous demand for a reduction in the cost of chip testing has forced both integrated 
circuit (IC) manufacturers and tester vendors to rethink how IC testing should be performed. 
According to industry studies, without re-engineering the projected cost of testers will 
continue to rise dramatically in the near future. 

[0004] A major reason for the high cost of test equipment is the specialized nature of 
conventional tester architecture. Each tester manufacturer has a number of tester platforms 
that are not only incompatible across companies such as Advantest, Teradyne and Agilent, but 
also incompatible across platforms within a company, such as the T3300, T5500 and T6600 
series testers manufactured by Advantest. Because of these incompatibilities, each tester 
requires its own specialized hardware and software components, and these specialized 
hardware and software components cannot be used on other testers. In addition, a significant 
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effort is required to port a test program from one tester to another, and to develop third party 
solutions. Even when a third party solution is developed for a platform, it cannot be ported or 
reused on a different platform. The translation process from one platform to another is 
generally complex and error prone, resulting in additional effort, time and increased test cost. 

5 [0005] In such specialized tester architecture, tester software such as the operating system 
and test analysis tools/applications run on a host computer. Due to the dedicated nature of the 
architecture, all hardware and software remain in a fixed configuration for a given tester. To 
test a hardware device or an IC, a dedicated test program is developed that uses some or all of 
the tester capabilities to define the test data, signals, waveforms, and current and voltage levels, 

1 0 as well as to collect the device under test (DUT) response and to determine DUT pass/fail. 
[0006] The testing of a wide variety of DUTs requires the hardware and software 
components of the tester system to exercise a wide range of functionalities and operations. 
During testing, different sets of vendor-supplied test modules may be utilized to support the 
wide range of functionalities, and the test system needs to be configured to support the vendor- 

1 5 supplied test modules and their corresponding calibration and/or diagnostics data in a plug- 
and-play manner. When a new vendor-supplied test module is utilized, calibration and/or 
diagnostics of the new test module may be required. In addition, the performance of a test 
module may be drifted outside the original calibrated range overtime, and the test module may 
need to be re-calibrated or re-diagnosed by the test system. 

20 [0007] Hence, there is a need for open architecture test systems that can be configured 
with different test modules based on testing requirements. Specifically, there is a need for 
open architecture test systems that can be configured to use vendor-supplied calibration and/or 
diagnostics (C&D) information in aplug-and-play manner during runtime. 

SUMMARY 

25 [0008] The open architecture test system of an embodiment of the invention permits the 
integration of third party test modules. The hardware and software framework of the test 
system includes standard interfaces with which modules from different vendors may interact 
in a plug-and-play manner. 
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[0009] In one embodiment, a method for integrating test modules in a modular test system 
includes creating component categories for integrating vendor-supplied test modules and 
creating a calibration and diagnostics (C&D) framework for establishing a standard interface 
between the vendor-supplied test modules and the modular test system, where the C&D 

5 framework comprises interface classes communicating vendor-supplied module integration 
information. The method further includes receiving a vendor-supplied test module, retrieving 
module integration information from the vendor-supplied test module in accordance with the 
component categories, and integrating the vendor-supplied test module into the modular test 
system based on the module integration information using the C&D framework. 

10 [0010] In another embodiment, a modular test system includes a system controller, at least 
one site controller coupled to the system controller, at least one vendor-supplied test module 
and its corresponding device under test (DUT), component categories for integrating vendor- 
supplied test modules, and a calibration and diagnostics (C&D) framework for establishing a 
standard interface between the vendor-supplied test modules and the modular test system, 

15 where the C&D framework comprises interface classes communicating vendor-supplied 

module integration information. The modular test system further includes means for receiving 
a vendor-supplied test module, means for retrieving module integration information from the 
vendor-supplied test module in accordance with the component categories, and means for 
integrating the vendor-supplied test module into the modular test system based on the module 

20 integration information using the C&D framework. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0011] The aforementioned features and advantages of the invention as well as additional 
features and advantages thereof will be more clearly understood hereinafter as a result of a 
detailed description of embodiments of the invention when taken in conjunction with the 
25 following drawings. 

[0012] Figure 1 illustrates an open architecture test system according to an embodiment of 
the present invention. 

[0013] Figure 2a illustrates a method for integrating vendor-supplied C&D information 
using a C&D framework according to an embodiment of the present invention. 
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[0014] Figure 2b illustrates the scheme used by the test system for accessing shared 
instrument according to an embodiment of the present invention. 
[0015] Figure 3a illustrates a waveform of a digital function generator module that 
calibrates its driver timing according to an embodiment of the present invention. 
5 [0016] Figure 3b illustrates a waveform of online compensation of driver timing 
calibration data according to an embodiment of the present invention. 
[0017] Figure 4 illustrates the integration of vendor-specific calibration information into 
an open architecture tester framework during runtime according to an embodiment of the 
present invention. 

1 0 [0018] Figure 5 Illustrates a method for implement a test condition memory according to 
an embodiment of the present invention. 
[0019] Like numbers are used throughout the figures. 
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DESCRIPTION OF EMBODIMENTS 
[0020] Methods and systems are provided for supporting calibration and/or diagnostics in 
an open architecture test system. The following description is presented to enable any person 
skilled in the art to make and use the invention. Descriptions of specific techniques and 
5 applications are provided only as examples. Various modifications and combinations to the 
examples described herein will be readily apparent to those skilled in the art, and the general 
principles defined herein may be applied to other examples and applications without departing 
firom the spirit and scope of the invention. Thus, the present invention is not intended to be 
limited to the examples described and shown, but is to be accorded the widest scope consistent 

1 0 with the principles and features disclosed herein, 

[0021] Figure 1 illustrates an open architecture test system according to an embodiment of 
the present invention. A system controller (SysC) 102 is coupled to multiple site controllers 
(SiteCs) 104. The system controller may also be coupled to a network to access associated 
files. Through a module connection enabler 106, each site controller is coupled to control one 

15 or more test modules 108 located at a test site 1 10. The module connection enabler 106 allows 
reconfiguration of connected hardware modules 108 and also serves as a bus for data transfer 
(for loading pattern data, gathering response data, providing control, etc.). In addition, 
through the module connection enabler, a module at one site can access a module at another 
site. The module connection enabler 106 allows different test sites to have the same or 

20 different module configurations. In other words, each test site may employ different numbers 
and types of modules. Possible hardware implementations include dedicated connections, 
switch connections, bus connections, ring connections, and star connections. The module 
connection enabler 106 may be implemented by a switch matrix, for example. Each test site 
1 10 is associated with a DUT 112, which is connected to the modules of the corresponding 

25 site through a loadboard 1 14. In one embodiment, a single site controller may be connected to 
multiple DUT sites. 

[0022] The system controller 102 serves as the overall system manager. It coordinates the 
site controller activities, manages system-level parallel test strategies, and additionally 
provides for handler/probe controls as well as system-level data-logging and error handling 
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support. Depending on the operational setting, the system controller 102 can be deployed on a 
CPU that is separate from the operation of site controllers 104. Alternatively a common CPU 
may be shared by the system controller 102 and the site controllers 104. Similarly, each site 
controller 104 can be deployed on its own dedicated CPU (central processing unit), or as a 

5 separate process or thread within the same CPU. 

[0023] The system architecture can be conceptually envisioned as the distributed system 
shovra in Figure 1 with the understanding that the individual system components could also be 
regarded as logical components of an integrated, monolithic system, and not necessarily as 
physical components of a distributed system. 

1 0 [0024] According to an embodiment of the open architecture test system of the present 

invention, the plug-and-play or replaceable modules is facilitated by use of standard interfaces 
at both hardware and software levels. A tester operating system (TOS) allows a user to write 
test plan programs using a test plan programming language, to operate the test system in a way 
specific to a particular device under test (DUT). It also allows for the packaging of sequences 

15 of the test system operations commonly used in test plan programs as libraries. These libraries 
are sometimes referred to as test classes, test templates, and other names. Vendor-supplied 
test modules are likely to require calibration of measurement/response values as well as means 
for diagnosing problems. A calibration and diagnostics (C&D) framework within the TOS 
needs to be able to invoke these capabilities for any module by using a standard interface. In 

20 this way, the proper behavior may be invoked for each test module without requiring any 
vendor-specific knowledge on the part of the TOS. This approach simplifies the TOS design 
and encapsulates the vendor's implementation of the module-specific C&D modules. 
[0025] In the embodiment of the open architecture test system, framework classes are used 
to enable, activate, control and monitor the modules. A framework is a set of classes and 

25 methods that implement common test-related operations. This includes classes for calibration 
and/or diagnostics, power supply, pin electronics sequencing, setting current/voltage levels, 
setting timing conditions, obtaining measurements, controlling test flow, etc. The framework 
also provides methods for runtime services and debugging. In one approach, framework 
objects are used to implement standard interfaces. A C++ based reference implementation of 
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the framework classes is provided to implement standard interfaces of the framework objects. 
The test system fUrther supports user specific framework objects. 

[0026] The open architecture tester system uses a minimum set of interfaces at the system 
framework level. The C&D framework is designed to operate on objects that present generic 

5 and universally applicable interfaces. "When a third party module vendor integrates its 
calibration and/or diagnostics software into the system, the vendor needs to provide new 
components supporting the same interfaces of the system as those interfaces supported by 
existing components. Such standard interfaces of an embodiment of the invention allow for • 
seamless integration of vendor-supplied modules into the system in a plug-and-play manner. 

10 [0027] In one embodiment, Standard Interfaces to the system TOS are defined as pure 

abstract C++ classes. Vendor-supplied module-specific calibration and/or diagnostics classes 
are provided in the form of executables, such as dynamic link libraries (DLLs), which may be 
independently and dynamically (on demand) loaded by the system software at runtime. Rach 
such software module is responsible for providing vendor-specific implementations for the 

1 5 system calibration and/or diagnostics interface commands, which comprise the application 
programming interface (API) for calibration and diagnostic software development. 
[0028] The requirement for performing calibration and/or diagnostics varies widely across 
modules of different types, as well as across modules of the same type from different vendors. 
The C&D framework's interface classes are designed to address such a wide variety of 

20 situations. Since the nature of the calibration and/or diagnostics modules and routines are 

widely variable, vendors provide information about their test modules in a standard way. Thus, 
the actual calibration and/or diagnostics routines are located in modules exposing standards, 
abstract interfaces, backed by implementations specific to that module type. In addition, there 
is a facility for invoking non-well-known interfaces in order to support vendor-specific 

25 calibration and/or diagnostics capabilities. 

Standard Calibration and Diagnostic Interfaces 

[0029] Figure 2a illustrates a method for integrating vendor-supplied C&D data using a 
C&D framework according to an embodiment of the present invention. As shown in Figure 2a, 
the C&D framework 200, illustrated as a unified modeling language (UML) class diagram. 
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includes a C&D vendor common information interface 202 (ICDVendCommonlnfo) wliich 
comprises mechanisms to allow the C&D jframework to obtain information about the contents 
of the calibration and/or diagnostics routine sets. The ICDVendCommonlnfo interface 202 
includes a number of routines and component modules, as well as the names and identifiers 
5 (IDs) of methods with non-standard interfaces. In one approach, the ICDVendCommonlnfo 
interface includes the following list of methods: getVendorlnfoQ, getModulelnfoQ, 
getDLLRevO, getLevelAndCategoryO, getGroupsQ, getThirdPartyAccessQ, getSwModulesQ, 
and runSwModulesQ. 

[0030] The getVendorlnfoQ method reads the vendor name of the hardware module that 

1 0 the DLL corresponds to. This vendor name string is intended to describe the name of the 
vendor, as related to its module ID. For example, if the hardware module is ADVANTEST's 
DM250MHZ module, then the string could be something like " ADVANTEST". The vendor 
name returned contains numeric and alphabetical characters ('a'-'z','A'-'Z','0-9'). 
[0031] The getModulelnfoQ method reads the module name of the hardware module that 

15 the DLL corresponds to. This module name string is intended to describe the name of the 
hardware module, as related to its module ID. For example, if the hardware module is 
ADVANTEST's DM250MHz module, then the string could be something like "DM250MHz". 
The module name returned contains numeric and alphabetical characters ('a'-'z',' A'-'Z','0-9')- 
[0032] The getDLLRevQ method reads the revision of this DLL in string. This interface is 

20 also used during the installation. 

[0033] The getLevelandCategoryQ method reads the supported levels and categories from 
the vendor module. According to the returned levels and categories, the framework will query 
the supported program groups using the method getGroupsQ. 
[0034] The getGroupQ method returns the program groups belong to the specified 

25 program level and category. The specified program level and category are the ones returned 
through the method getLevelAndCategoryQ. 

[0035] The getThirdPartyAccessQ method gets information about a Third Party Access 
(TPA) method for the whole calibration and diagnostic module. By using this, the vendor 
module may plug in a vendor specific property displayed on a Calibration and Diagnostics 



wo 2005/114239 



PCT/JP2005/009811 



9 

GUI tool. If the vendor C&D module does not need to have this interface, then a null pointer 
is returned from this method. 

[0036] The getSwModulesQ method sets the detailed calibration or diagnostic program 
name to the framework. If the module has a set of programs that belong to the specified level 

5 and the category and group, the implementation of this method has to return the set of program 
information to the framework through a program information method. The level, category, 
group are used to classify the programs in the GUI tool. Since it doesn't create a scope for the 
program names, the program identifier (progID) may be unique in a particular calibration or 
diagnostics software module. 

1 0 [0037] The runSwModulesO method asks the module to execute a selected program. One 
program may be selected at a call. The framework has the sequence of the programs selected 
by the user in GUI tool, and it calls this method through the responsible modules. The user 
may select the hardware entity (a channel, in general) to run the program. This information is 
passed through a parameter env. Each program code needs to run on the selected hardware 

15 entity. 

[0038] The UML diagram of Figure 2a also includes a module configuration data 204, a 
module manager 206, a system control C&D framework 208, a site controller C&D 
framework 210, a system controller 212, a site controller 214 and a C&D GUI tool 216. The 
UML diagram further includes a vendor calibration common information object 218 which 
20 retrieves information from a vendor calibration DLL object 220; and a vendor diagnostic 
common information object 222 which retrieves information from a vendor diagnostic DLL 
object 224. 

[0039] The test system is configured by the module configuration data 204. The module 
manager 206 manages vendor-supplied driver software, calibration software, and diagnostic 
25 software. The C&D framework retrieves the vendor calibration and diagnostic program 

information through the ICDVendCommonlnfo interface 202 according to the configuration 
data held in the module manager. Each vendor may implement, in its own specific way, a 
vendor calibration common information object (VendorCal's Commonlnfo) 218 or a vendor 
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diagnostic common information object (VendorDiag's Commonlnfo) 222 derived for its 
calibration or diagnostics functionalities respectively. 

[0040] The C&D framework passes the vendor C&D software information to a C&D 
graphical user interface (GUI) tool 216 running on the system controller 212. When a user 

5 operates the C&D system through this C&D GUI tool 216, the user may choose from the set 
of C&D programs retrieved from all vendor C&D software loaded in the current system 
configuration. The C&D framework 208 in the system controller distributes the selected 
program(s) to the responsible site controllers 214, and then the C&D framework 210 in the site 
controller executes the programs on the appropriate vendor C&D modules, using the 

1 0 ICDVendCommonlnfo Interface 202. Thus, by using the ICDVendCommonlnfo interface 202, 
the C&D framework provides vendors a set of standard interfaces for integrating vendor- 
supplied C&D modules into the test system. 

[0041] In addition to the ICDVendCommonlnfo interface 202, the C&D framework 
further includes the following interfaces: 
15 □ ICDVendFwCtrl 



This interface provides a framework supported utility used by vendor components to 
access C&D framework environment settings required for the execution of the vendor 
program. This includes algorithm versions, calibration data revision settings, etc. 



a 



ICDVendIO 



20 



This interface provides a framework supported utility used by vendor components to 
produce standardized messages to be directed to the C&D GUI tool, or other 
applications running on the System Controller, as well as providing for datalogging 
services. 



25 



□ 



ICDProgress 

This interface provides a framework supported utility used by vendor components to 
transmit the status of vendor program execution (e.g., "percentage complete" 
information, etc.). This interface is also used to halt C&D execution flow invoked 
from C&D GUI tool or to pause or resume execution. 



□ 



ICDVendCalData 



30 



This interface provides a framework supported utility used by vendor components to 
read and write system files such as calibration data, etc. 
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□ ISysDeviceSiteMgr 

The system device site manager (ISysDeviceSiteMgr) interface provides a framework 
supported utility used by vendor components to access shared system devices or 
instruments. For example, it provides access to the instruments on the System 
Controller, connected through a GPIB bus, or by RS-232C. Proxy objects, such as 
IGPIBDeviceProxy and IRS232Proxy, are provided. These give the vendor modules 
remote access to the devices or instruments installed on the System Controller. Figure 
2b illustrates the scheme used by the test system for accessing shared instrument 
according to an embodiment of the present invention. 

Runtime Calibration 

[0042] Runtime calibration is a set of calibration activities that may be invoked from test 
classes or from the C&D framework while the system is loading or executing a test plan 
program. In one embodiment, the method of performing runtime calibration includes: ' 

□ Ascertaining hardware module status: 

The TOS determines whether ail modules have been calibrated and are ready to test the 
DUT. 

□ Loading calibration data (stored during a previous calibration operation): 
The TOS initializes the modules by loading module-specific calibration data. 

□ Time Domain Reflection (TOR) and timing calibration data compensation: 

A user may compensate module-specific timing calibration data, which is used with a 
particular performance board (or loadboard). Note that the system timing calibration 
does not take into account the propagation delays of the trace lines on the particular 
performance board chosen by the user at device test time, as a performance board is 
designed for a particular DUT type. Since there is non-zero delays on the lines from 
the tester module channels to the DUT pins, the timing calibration data needs to be 
compensated with regard to the length of the trace lines on the performance board. 
Time Domain Reflection (TDR) is a method used to measure the length of trace lines 
using electric reflection, and the measured data is then used to compensate the timing 
calibration data. Also note that since the timmg calibration data is specific to each 
vendor-supplied module, the data compensation process becomes specific to the 
vendor-supplied module. 

□ Online timing calibration data compensation: 

The TOS and user are able to compensate module-specific timing calibration data with 
regard to changes dictated by conditions occurred during test execution, performance 
board effects, and other factors. In other words, the timing calibration data often needs 
to be compensated according to the actual conditions of the test. 
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In one embodiment, Figure 3a illustrates a digital function generator module that 
calibrates its driver timings to assure that the specified timing is generated at a 50% 
point 302 of Vih (high driver voltage) 304 and Vil (low driver voltage) 306. 

The digital function generator module has two online calibration parameters, Vih 304 
5 and Vil 306, which are used to specify the 50% point of the driver voltage amplitude. 

The base timing calibration data is obtained with a set of predefined voltage 
amplitudes. For example, with Vih = 3V and Vil = OV, a 50% point of Vih and Vil is 
at 1 .5 V. The Vih and Vil values are used to compensate this timing calibration data for 
the driver timing during device test execution. As shown in Figure 3b, if the driver of 
10 a pin (or pin group) is programmed to have Vih = 1 .OV (308) and Vil = OV (310) 

during a test, the 50% point 312 of this driver amplitude is 0.5 V. Online calibration is 
employed to use the specified Vih and Vil values to compensate the timing calibration 
data so that it is adequate for these operative driver voltages. 

[0043] In an open architecture test system, the hardware resource representation used in 

1 5 the test plan program language is vendor independent. For example, a user is allowed to 
declare a pin group not only with individual pins provided by a particular vendor, but also 
with pins provided by other vendors, as long as such pins satisfy certain system requirement 
(if any). Since a test class uses the hardware representation specified in a test plan program, it 
supports this type of vendor independent (i.e., logical) hardware representation. Even if the 

20 vendor-specific runtime calibration implementations are exposed by the system through an 
interface, for example through an interface class ICDVendRtCal, the actual implementations 
may be different. Thus, each vendor-specific runtime calibration component has a different 
access handle for its functionality. A test class developer (i.e., the user) needs to obtain 
vendor-specific access handles associated with the same logical hardware representation 

25 separately, and processes each access handle separately (each of which is responsible for the 
particular vendor-specific hardware resources extracted fi-om the same logical hardware 
representation). In order to avoid this complexity during test class development, the C&D 
framework hides this complexity, and provides a proxy implementation with the 
ICDRuntimeCal interface. 

30 [0044] Figure 4 is a UML class diagram that illustrates the integration of vendor-specific 
calibration information into an open architecture tester frameworl< during runtime according to 
an embodiment of the present invention. The UML diagram includes a C&D vendor runtime 
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calibration (ICDVendRtCal) interface 402, a C&D runtime calibration (ICDRuntimeCal) 
interface 404 and a C&D runtime system (ICDRuntimeSys) interface 406. The ICDVendRtCal 
interface 402 contains mechanisms to allow the framework to obtain the particular 
implementation of a vendor-specific runtime calibration routine set. The ICDRuntimeCal 
5 interface 404 allows users to access different vendor-specific implementations of the 
ICDVendRtCal runtime calibration interface 402. The UML diagram of Figure 4 further 
includes a site controller 214, a site controller C&D framework 210, a vendor runtime 
calibration class 408, a runtime calibration class 410 and a test class 412. 
[0045] In one embodiment, the ICDVendRtCal interface 402, ICDRuntimeCal Interface 
1 0 404, and ICDRuntimeSys interface 406 include one or more of the following methods: 
getSwModuleO, getAlgRevQ, islnitialized(), loadDCCalDataQ, loadACCaiDataQ, 
getAttributeCacheO, tdrCalQ, getTdrCalDataFroraFile(), putTdrCalDataToFileQ, mergeCalQ, 
and loadACCaiDataQ. 

[0046] The getAlgRev() method returns the algorithms or the data type name the test 
15 module supports. The C&D framework requests the default revision and the supported 

revisions via the getAlgRevQ method. The revision selection is made by the user on the C&D 
GUI tool. The framework provides a utility for the vendor module in order to read the 
selected revision. The test module uses the selected revision to support bundle capabilities. 
[0047] The isInitializedQ method is called by the C&D framework to determine whether 
20 the test modules are initialized. 

[0048] The loadDCCalDataQ method is called when the DC calibration data needs to be 
loaded onto the hardware modules in order to be ready to be operated. The framework queries 
the modules that they're ready or not by calling isInitializedQ method on the vendor modules, 
and call this fiinction on demand to load the DC calibration object for the particular module. 
25 The vendor modules obtain the algorithm revision that the user wants to use. The 
functionalities for this activity are provided by the C&D framework. 
[0049] The loadACCaiDataQ method is called when The AC calibration data needs to be 
loaded onto the hardware modules in order to be ready to be operated. The framework requests 
the modules that they're ready or not by calling isInitializedQ method on the vendor modules, 
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and call this function on demand to load the AC calibration for the particular module. The 
vendor modules obtain the algorithm revision that the user wants to use. The functionalities 
for this activity are provided by the C&D framework. The standard AC calibration data is the 
calibration data measured for the default condition. This default condition is decided by 
5 vendor hardware module. For example, ADVANTEST DM250MHz module measures the 
standard AC calibration data with 0v-3v driver voltage swing. 

[0050] The method getAttributeCacheQ method obtains an ICDCalAttributeCache object. 
ICDCalAttributeCache is a vendor module specific interpreter of the parameter-value pairs 
described in calibration block in the Oasis Test Program Language (OTPL). The calibration 

1 0 block describes the condition for the online calibration condition. Each vendor hardware 
module needs to have different set of parameters as the online calibration condition. 
[0051] These online calibration parameters are listed in the resource file. If the resource 
type supported by any particular module has the online calibration parameters, it needs to be 
listed in the correspondent resource file. The resource files are read by the system and used to 

1 5 determine what calibration module is responsible to accept the parameters specified in the 
calibration block. 

[0052] ICDCalAttributeCache is the interface to provide the methods to set the vendor 
hardware module specific online calibration parameters and also to write it to the hardware 
module. The calibration module developers implement this interface which returns an instance 

20 for a particular resource type through getAttributeCacheQ, if the hardware module requires the 
calibration data compensation according to the condition in which user uses this particular 
module. The framework passes the online calibration parameters to this instance, and call 
applyO method to write it to the hardware module. The parameters are stored in Test 
Condition Memory (TCM) and the framework will give an ID for a set of 

25 ICDCalAttributeCache objects that realize a test condition. 

[0053] The tdrCalQ method measures the length of the cable on the particular channel by 
using Time Domain Reflection (TDR) method in order to compensate the calibration data. 
This method is implemented for the hardware modules that require this functionality. 
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[0054] The getTdrCalDataFromFileO method reads the TDR data file, which is created by 
tdrCalQ method. The vendor implementation needs to read the TDR data file for the 
performance board identifier. This method reads the TDR data of the pins in the data file. 
[0055] The putTdrCalDataToFileQ method writes the TDR data file. This method is used 
5 by a user who wants to create TDR data file from other user oriented data file, or who wants to 
compensate TDR data measured by tdrCalQ. 

[0056] The mergeCalQ method compensates the standard AC calibration data with the 
TDR result data. The standard AC calibration or the arbitrary calibration data needs to be 

loaded before calling this method. 
1 0 [0057] The loadACCalData() method is called when the user tries to load the standard AC 

calibration or the arbitrary AC calibration or the merged AC calibration data from the data file. 

When the destination is the Test Condition Memory, the block identifier is specified to TcmlD. 

The created Test Condition Memory block would be selected by selectTestConditionQ method, 

The specified TcmID may be used by the system to revert the calibration data back from the 
1 5 online calibration data to the original calibration data loaded by this method at test execution 

time. If the user does not use this method to load the data onto the Test Condition Memory, the 

system calls selectTestConditionQ on the vendor module with the unknown TcmlD. The 

vendor module returns an error in this situation. 

Use of Test Condition Memory 
20 [0058] Runtime calibration activities may be performed during test plan program 

execution. For example, online calibration may be done every time after any condition that 
may cause a loss of the system accuracy is detected. This online calibration causes an 
overhead for test execution time, and which in turn may reduce the productivity of the test 
system. 

25 [0059] In order to alleviate this overhead, according to another embodiment of the present 
invention, the test system preloads a set of predefined calibration data, and stores it in a test 
condition memory. The test condition memory (TCM) is a condition data cache for storing 
test conditions, and it can effectively transfer a test condition data from the TCM to hardware 
registers. This test condition memory may be implemented by either software or hardware. 
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The C&D framework will create, select, delete test conditions using a ITCMManipulator 

interface that has the following methods implemented by vendor calibration modules. 

OFCStatus openTCMEntry(TCMID_t condition); 
OFCStatus closeTCMEntry(TCMID_t condition); 
5 OFCStatus selectTCMEntry(TCMID_t condition); 

OFCStatus removeTCMEntry(TCMID_t condition); 

TCMIDJ is an identifier of a Test Condition. The framework will specify an identifier for 
creation (openTestConditionQ and closeTestConditionQ), selection (selectTestConditionQ), 
deletion (removeTestConditionQ) of a Test Condition. The TCMManipulator is returned by 
1 0 the ICDVendRtCal: :getTCMManipulatorO. 

[0060] During test plan program execution time, the C&D framework selects the 
appropriate test condition memory blocks, and transfers them to the corresponding hardware 
module registers. Figure 5 illustrates a method for implement a test condition meniory 
according to an embodiment of the present invention. The method includes a test condition 

1 5 memory manipulator interface (ITCMManipulator) 502, a C&D vendor runtime calibration 
interface 402, and a vendor runtime calibration data object 408. The ITCMManipulator 
interface 502 is used by the C&D framework to manipulate the test condition memory. By 
implementing this interface, any vendor's test condition data can be integrated and loaded into 
the TCM seamlessly, thereby reducing the calibration overhead of the test system. 

20 [0061] There are several benefits achieved by the disclosed C&D framework. First, it 
enables multi-vendor (i.e., third party) software and instruments to be developed, certified 
individually, and Integrated reliably into the test system, while not requiring any vendor- 
specific, proprietary treatment for calibration and/or diagnostics of the instruments. In 
addition, the disclosed C&D framework organizes vendor-supplied calibration and/or 

25 diagiiostics modules into separate components, thereby providing seamless support for 

integration and use of a particular vendor-supplied component. Moreover, the disclosed C&D 
framework provides a remote access scheme for sharing system instruments by module C&D 
components. Furthermore, the C&D framework provides mechanisms for storing calibration 
data in a test condition memory, which reduces test program runtime overhead typically 

30 incurred during testing due to re-calibrations of the test system. 
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[0062] One skilled in the relevant art will recognize that many possible modifications and 
combinations of the disclosed embodiments may be used, while still employing the same basic 
underlying mechanisms and methodologies. The foregoing description, for purpose of 
explanation, has been described with references to specific embodiments. However, the 
5 illustrative discussions above are not intended to be exhaustive or to limit the invention to the 
precise forms disclosed. Many modifications and variations are possible in view of the above 
teachings. The embodiments were chosen and described to explain the principles of the 
invention and its practical applications, and to enable others skilled in the art to best utilize the 
invention and various embodiments with various modifications as are suited to the particular 
1 0 use contemplated. 
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CLAIMS 

What is claimed is: 

1 . A method for integrating test modules in a modular test system, comprising: 
creating component categories for integrating vendor-supplied test modules; 
creating a calibration and diagnostics (C&D) framework for establishing a standard 

interface between the vendor-supplied test modules and the modular test system, wherein the 
C&D framework comprises interface classes communicating vendor-supplied module 
integration information; receiving a vendor-supplied test module; 

retrieving module integration information from the vendor-supplied test module in 
accordance with the component categories; and 

integrating the vendor-supplied test module into the modular test system based on the 
module integration information using the C&D framework. 

2. The method of claim 1 , wherein the component categories comprise one or more 
elements selected from the group consisting of driver software, calibration software, and 
diagnostic software. 

3. The method of claim 1, wherein the interface classes comprise: 
a module manager for obtaining module configuration data; 

a vendor command information interface for obtaining a vendor calibration DLL and a 
vendor diagnostic DLL; 

a site controller framework for interfacing with one or more site controllers; and 
a system framework for interfacing with a system controller. 

4. The method of claim 1, wherein the interface classes are defined as C++ classes. 
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5 . The method of claim 1 , further comprising: 

storing the module integration information in a test condition memory; and 
performing calibration of the vendor-supplied test module based on the module 
integration information stored in the test condition memory. 

6. The method of claim 1 , further comprising: 

storing the module integration information in a test condition memory; and 
performing diagnostics on the vendor-supplied test module based on the module 
integration information stored in the test condition memory. 

7. The method of claim 5, wherein performing calibration comprises: 
providing a runtime calibration interface; and 

performing runtime calibration of the vendor-supplied test module based on the 
runtime calibration interface. 

8. The method of claim 7, wherein the runtime calibration interface comprises: 

a system interface for communicating with the vendor-supplied test module via a site 
controller; 

a calibration interface for communicating test class information with a user; and 

a vendor interface for communicating vendor-supplied calibration information with a 

vendor. 

9. The method of claim 7, wherein performing runtime calibration comprises : 
obtaining hardware module status; loading calibration data; 

performing time domain reflection; performing timing calibration data compensation; 

and 

performing online timing calibration data compensation. 
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10. The method of claim 1 , wherein retrieving comprises loading the module integration 
information dynamically during runtime. 

11. The method of claim 1 , wherein retrieving comprises loading the module integration 
5 information independently during runtime. 

12. The method of claim 1, wherein integrating comprises calibrating the vendor-supplied 
test module based on the module integration information. 

10 13. The method of claim 1 , wherein integrating comprises diagnosing the vendor-supplied 
test module based on the module integration information. 

14. A modular test system, comprising: 
a system controller; 
1 5 at least one site controller coupled to the system controller; 

at least one vendor-supplied test module and its corresponding device under test 

(DUT); 

component categories for integrating vendor-supplied test modules; 

a calibration and diagnostics (C&D) framework for establishing a standard interface 
20 between the vendor-supplied test modules and the modular test system, wherein the C&D 
framework comprises interface classes communicating vendor-supplied module integration 
information; 

means for receiving a vendor-supplied test module; 

means for retrieving module integration information from the vendor-supplied test 
25 module in accordance with the component categories; and 

means for integrating the vendor-supplied test module into the modular test system 
based on the module integration information using the C&D framework. 
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15. The system of claim 14, wherein the component categories comprise: driver software; 
calibration software; and diagnostic software, 

16. The system of claim 14, wherein the interface classes comprise: 
a module manager for obtaining module configuration data; 

a vendor command information interface for obtaining a vendor calibration DLL and a 
vendor diagnostic DLL; 

a site controller framework for interfacing with one or more site controllers; and 
a system framework for interfacing with a system controller. 

17. The system of claim 14, wherein the interface classes are defined as C++ classes. 

18. The system of claim 14, further comprising: 

a test condition memory for storing the module integration information; and 
means for performing calibration of the vendor-supplied test module based on the 
module integration information stored in the test condition memory. 

1 9. The system of claim 1 4, further comprising: 

a test condition memory for storing the module integration information; and 
means for performing diagnostics on the vendor-supplied test module based on the 
module integration information stored in the test condition memory. 

20. The system of claim 1 8, wherein the means for performing calibration comprise: 
a runtime calibration interface; and 

means for performing runtime calibration of the vendor-supplied test module based on 
the runtime calibration interface. 

2 1 . The system of claim 20, wherein the runtime calibration interface comprises: 
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a system interface for communicating witii the vendor-supplied test module via a site 
controller; 

a calibration interface for communicating test class information with a user; and 

a vendor interface for communicating vendor-supplied calibration information with a 

5 vendor. 

22. The system of claim 20, wherein the means for performing runtime calibration 
comprise: 

means for obtaining hardware module status; 

10 means for loading calibration data; 

means for performing time domain reflection; 

means for performing timing calibration data compensation; and 

means for performing online timing calibration data compensation. 

15 23. The system of claim 14, wherein the means for retrieving comprise means for loading 
the module integration information dynamically during runtime. 

24. The system of claim 14, wherein the means for retrieving comprise means for loading 
the module integration information independently during runtime. 

20 

25 . The system of claim 14, wherein means for integrating comprise means for calibrating 
the vendor-supplied test module based on the module integration information. 

26. The system of claim 14, wherein means for integrating comprise means for diagnosing 
25 the vendor-supplied test module based on the module integration information. 
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